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Description 

This invention relates to a system for controlling ac- 
cess privileges to data within a data processing system. 

In a relational database, data is viewed as rows and s 
columns, where a row represents a record, in tables. In 
order to retrieve records that represent the spanning of 
multiple tables, relational operators, such as a join op- 
eration, are utilised. Although relational operators are 
used within applications or by users through a query lan- 
guage, these relational operations are not incorporated 
within the data such that the relational database man- 
ager can automatically intuit such relationships. In order 
to retrieve a record from the database, the user must 
have read permission for that record. In order to change 
the data in the record, the user must retrieve (select and 
fetch) the data into memory, update the record in mem- 
ory, and then write the updated record to the database. 
The user must have permission to write the record be- 
fore the database manager allows the previous data to 
be overwritten in the database. Moreover, in order to up- 
date the record in memory, the user must be cognizant 
of the column's attributes, such as whether that column 
contains integers, characters, strings etc. 

In an object oriented database, the navigation 
through the data is similar to that of the network model 
where an object oriented database manager traverses 
the relationships defined amongst the objects and sub- 
objects. In contrast to the relational database model, re- 
lationships between objects and subobjects are defined 
through the data, and not through explicit operations. 
Moreover, in complex application environments, objects 
and their relationships usually show very complex inter- 
nal structures and comprise larger numbers of proper- 
ties; such properties include methods. In addition, the 
object oriented database model parallels the object ori- 
ented programming model in that one may inherit at- 
tributes and methods from predecessor objects. How- 
ever, the object oriented programming model generally 
deals with objects that are temporal in nature, i.e., mem- 
ory resident. The object oriented database model ex- 
tends the programming model by allowing one to deal 
with objects that persist, i.e., are disk resident. One of 
the features of object oriented databases (analogous to 
the programming model) is to provide the ability to de- 
fine generic operations, i.e. methods, which apply to the 
objects, for the purposes of manipulating and retrieving 
them. In the relational database model, all operations to 
retrieve and manipulate records are performed by using 
the database manager's application programming inter- 
face or query language. The object oriented methodol- 
ogy insulates the users of the database from the data 
representation and/or data structures that comprise ob- 
jects. All retrieval and update operations may be per- 
formed through the use of these methods. 

In the relational database model, access privileges 
may be set on the records such that grant and revoke 
authorisation privileges can be determined per user of 



the database. The records are tagged with either read 
or write privileges for specific users. For example, the 
first record could be read by users A, B, and C, and only 
written by user C. Likewise, the second record could be 
tagged such that only user A has the permission to read, 
and only user A has the permission to write. 

For example, if a database contained payroll infor- 
mation, members of the payroll department may be able 
to read all of the payroll information for all departments 
except the payroll record for their payroll department. 
Only the manager of the payroll department would have 
the permission to read the record containing the payroll 
department data. If a user attempted to retrieve the 
records which did not define read privilege for the user, 
that user would not be granted the ability to see that 
record of data. 

One shortcoming of relational databases is that ac- 
cess permission control is on a record basis. 

1 989 IEEE Computer Society Symposium on Secu- 
rity and Privacy, May 1-3, 1989, Oakland, California, 
pages 110-115 describes an authorization model for ob- 
ject oriented databases in which authorization rules are 
placed at various parts of an object hierarchy and eval- 
uated against access requests using an algorithm which 
searches the object hierarchy for a rule authorising the 
requested access. 

This invention provides an object oriented database 
system as defined in the claims. 

An embodiment of the invention will be described in 
the ensuing description with relerence to the following 
figures, wherein 

Fig. 1 is a block diagram of the system of this em- 
, bodiment having an object data manager for con- 
trolling the access to objects in an object database 
according to an access control policy associated 
with the objects and the user's credentials. 

Fig. 2A is a hierarchy of objects in an object data- 
base showing superobjects, objects, and subob- 
jects. 

Fig. 2B is an illustration of an access control list for 
each object in an object database. 

Fig. 2C is a hierarchy of interface menu objects in 
and object database showing superobjects, ob- 
jects, and subobjects. 

Fig. 3A is a flow diagram of the object data manager 
utilising the access control facilities to determine 
whether a particular operation against a set of ob- 
ject classes and objects are permitted. 

Fig. 3B is a flow diagram of the methodology for 
granting or revoking the operations based on the 
access control policies. 
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Fig. 3C is a continuation of the flow diagram of Fig. 
3A. 

Fig. 4 illustrates the structure of the access control 
list. s 

Fig. 5A shows the access control policy of this em- 
bodiment used in conjunction with a system man- 
agement interface tool for controlling the adminis- 
trative views of menu objects. 

Fig. 5B shows a hierarchy of system management 
interface menu option objects. 

The data processing system 1 has an operating 
system running in memory 3 which has tables 30 which 
contains the credentials 31 for each active user 32. The 
credentials identity 31 contains the user id 33, and the 
group ids 34 for which the user belongs and other se- 
curity information 35. In user memory 4, the object data 
manager 40 accesses the objects found in the file sys- 
tem. The file system 20 resides on disk 2 which has ob- 
ject classes 50, as shown in Fig. 2A and Fig. 2C. 

Referring to figure 2A, object class 54 is a super 
class of objects 55 and objects 56, and objects 55 is a 
superclass of objects 57. An example is described in 
EP-A-0 398 643. Likewise, objects 55 are a subclass of 
object class 54, and object classes 57 are subobjects of 
object class 55. The object class of the system manage- 
ment interface tool comprises interface menu option ob- 
jects, as shown in Fig. 2C. An example of such an inter- 
face tool is described in EP-A- 398 646. 

Referring back to Fig. 1 t the object data manager 
40 is cognizant of absolute access control policy assign- 
ment and authorisation per object. The authorisation 
process reviews the user's credentials 31 described to 
the object data manager 40 and uses this information to 
determine the operations which are permissible on each 
object. 

When the object data manager is requested to per- 
form operations on specific objects, i.e. retrieve or mod- 
ify, the object data manager first determines the current 
credential attributes 31 for the user 32 requesting the 
operation by interfacing with the kernel 3. The object da- 
ta manager then performs the operation which may re- 
quire inheritance or subclass traversal through the ob- 
jects. As the object data manager performs such an op- 
eration, the access control policies lists are checked for 
each object satisfying the criteria of the operation. Ac- 
cess control policies are treated like other attributes 
within an object class in that they may be inherited from 
other superclasses, thus altering the access control pol- 
icies as traversal of the objects is performed. 

Fig. 2B represents a user defined view of the devic- 
es object class 54 and one of its subclasses, customised 
devices 55. Devices object class 50 contains attributes 
71 , methods 72 and triggers 73. For example, for an ob- 
ject class of customised devices devices 55, the at- 



tributes 71 would represent the definition of the object 
such as device name 74 character string, device id 75 
integer number, and device type 76 character string, etc. 
The methods 72 are the operations that apply to the ob- 
ject. For example, a method of configuring the device 
77, the method of defining the device 78, the method of 
unconfiguring 79, and the method of undefining 80 the 
object, etc. Triggers 73 represent the events that are au- 
tomatically invoked when the objects are manipulated. 

In addition to the user defined attributes 71 , the ob- 
ject data manager transparently maintains a separate 
access control list 1 00 as part of each object within each 
object class. The access control list is further shown in 
Fig. 4. The access control list 1 00 maintains the owning 
user id 101 and the owning group id 102 for each object. 
This owning information 101, 102 dictates the access 
control policy for maintenance to the access control list 
itself. Only those owning users and owning groups can 
alter the access control list in an object. Before any ac- 
cess control entry is altered for any object, the object 
data manager first verifies that the user can be identified 
through its credentials in either the owning user id 101 
or the owning group id 102. 

The access control attributes on each object con- 
sists of eight 32 bit entries 111-118, of which seven of 
these entries 111-117 represent the user or group ids 
making up the access control list 100. The eighth entry 
118 is divided into eight 4-bit slots 121-128, where the 
first seven slots 121-127 represent the privileges asso- 
ciated with the corresponding access control entry 
111-117. The eighth 4-bit slot 128 is used to keep the 
count of the number of entries used. In the first seven 
4-bit slots 121-127, the first three bits represent read, 
write, and execute privileges while the last bit of the 4-bit 
slot indicates whether the corresponding access control 
entry applies to a user or a group id. 

Fig. 3A illustrates the high level flow of the object 
data manager utilising the access control facilities to de- 
termine whether a particular operation against a set of 
object classes and objects are permitted. The object da- 
ta manager opens the appropriate object classes, step 
301 , and determines if the open succeeded, step 302. 
The object data manager then iterates for each object 
class that was opened, step 303. When the list of object 
classes opened are processed, the results are accumu- 
lated and returned to the user, step 304. If there are ob- 
ject classes to process, the object data manager ac- 
quires the user's credentials from the operating system 
(resultant is the least privilege associated for that user 
based on the set's credentials), step 305. The object da- 
ta manager then performs the retrieval of the selected 
objects, step 306, and checks to see if the object is avail- 
able for further processing, step 310, specifically wheth- 
er the access privileges for the user do not conflict with 
the access controls assigned to the object being ac- 
cessed. Specifically, the object data manager checks in 
the operating system for the credentials for the user, and 
checks these credentials with the list of access control 
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privileges defined by the objects retrieved. If the access 
privileges are denied; the object data manager then 
checks to see if there are more objects that meet that 
selection criteria, step 315. If so, the object data man- 
ager returns to step 305. If not, the object data manager 5 
returns to step 303. Given that the object holds the ap- 
propriate access controls for further processing, step 
320, the object data manager performs the specific op- 
erations generally defined by the methods. The object 
data manager accumulates the new set of access con- 
trol information for the user based on the bitwise ANDing 
of the object's access controls, step 325 and returns to 
step 315 to determine whether there are more objects 
to retrieve. In step 325, the object data manager uses 
this technique to inherit the least access privilege that 
spans the objects of interest. 

Fig. 3B describes in more detail step 310 from Fig. 
3A which describes the methodology for granting or re- 
voking the operations based on the access control pol- 
icies. The access control facility first determines wheth- 
er the requested modes supplied to it are valid, step 328. 
Given that the modes are valid, the object data manager 
defines a bit mask which is representative of the re- 
quested modes, step 331. In addition, the object data 
manager accesses the in memory version of the access 
control list assigned to a particular object, step 335. 
Once the access control list has been acquired, the ob- 
ject data manager determines the number of entries uti- 
lised within the list, step 337. If the count is not greater 
than zero, step 331 , the object data manager grants ac- 
cess to the object by the user, step 341. If the count is 
greater than zero, the object data manager compares 
the user's credentials to the access control entry repre- 
senting either a user or a group, step 344. If there is a 
match, the object data manager saves the index of the 
matching access control entry, step 346. It then checks 
to see if there are additional access control entries, step 
352, and if so, returns to step 344. If additional entries 
do not exist, the object data manager determines if there 
were any matches between the user's credentials and 
the object's access control entry, step 355. If there are 
none, the access is denied to the object for that user, 
step 357. If a match exists, the object data manager ac- 
quires the privilege bit mask defined for that user on that 
object, step 359, Fig. 3C. The object data manager then 
checks to see if the requested bit mask is greater than 
the user's bit mask defined by the access control entry 
within that object, step 361. If the requested bit masks 
is greater, then access is granted to the object for that 
user, step 363, If the requested bits are less than or 
equal to, then a bitwise AND operation is performed be- 
tween the requested bit mask and the bit mask found in 
the objects entry for that user, step 365. If the resultant 
is greater than zero, step 367, then access is granted to 
the object for that user, step 369. If the resultant is less 
than or equal to zero, then access is denied to that object 
for that user, step 372. 

If a particular user is associated with multiple 



groups, and identifies oneself with multiple groups when 
performing operations on the objects, the object data 
manager will perform a bitwise AND operation of the 
particular sets of credentials that are currently associat- 
ed with that user. This results in a assigning the least 
privilege associated with the intersection of the creden- 
tials sets. 

The above described access control policies can be 
applied to various applications. An example of such an 
application is described in EP-A-398 646. The access 
control lists of this embodiment can be applied to a sys- 
tem management interface tool for the purposes of de- 
fining the authorisation policies for the various views that 
may be accessed by a collection of system administra- 
tors with various authorities. Without this embodiment, 
one approach would be to define the collection of men- 
us, dialogs, and prompts to represent the permutations 
of the various administrative views associated with the 
different administrative privileges. However, this tech- 
nique typically results in very large databases contain- 
ing a great deal of redundant information. 

In contrast, with the present embodiment, the vari- 
ous menus, dialogs, and prompts are only stored once 
in the object database, and are assigned the appropriate 
access controls on the various objects (menus, dia- 
logues, prompts) such that the various permutations of 
administrative views are dictated by the access control 
policies. 

For example, Fig. 5B shows a hierarchy of interface 
menu option objects for performing system manage- 
ment tasks, 500. Along with security and users, 504, oth- 
er subclasses of system management interface objects 
include devices, TCP/IP, physical and logical storage, 
communications applications and services, problem de- 
termination, etc. As shown in Fig. 5A, administrator A, 
551 , may have read, write, and execute privileges for 
the user interface objects 553 which present the config- 
urable domain of TCP/IP, devices, and users while ad- 
ministrator B, 552, may have read, write, and execute 
privileges for the user interface objects which present 
the configurable domain of just users, 554. However, ad- 
ministrator A, 551 , may only have the privilege to access 
to view the users 542 and the groups 543, while admin- 
istrator B, 552, has access to view and manage the ac- 
cess control lists, 541, the users 542, the groups, 543, 
and passwords, 544. Therefore, administrator A would 
only have access to menus 542, 543, while administra- 
tor B would have access to menus 542, 543, 544, 541 
as the subobjects of the configurable domains menu ob- 
ject class for users. 

There has been described a system in which grant 
and revoke permissions, referred to herein as access 
control lists apply to a collection of objects in an object 
oriented database. An object data manager supports 
composite objects which are multiple objects and the ac- 
cess control policies that apply to such objects are trans- 
parent to the user. The access control lists span across 
the objects. Furthermore, not only do the access control 
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lists provide read and write permissions, but they also 
provide execution permission for operations which ap- 
ply to the objects. The execute semantics apply to meth- 
ods that are invoked to perform operations on the ob- 
jects. A user with execute permission can perform op- 
erations on those objects. 

For example, if the objects in the object oriented da- 
tabase contained information on the configuration of a 
data processing system, a user could be either granted 
or revoked the permission not only to read the configu- 
ration data, but also to perform configuration operations 
on the data. If the configuration information contained 
information on the physical devices in the system, the 
user would be granted or revoked the permission to con- 
figure, define, start, stop, unconfigure, and undefine 
those devices. 



Claims 

1. An object oriented database system comprising a 
hierarchy of objects (54, 55, 56, 57, 58) and an ob- 
ject data manager (40) for accessing the objects, 
characterised by one or more tables (30) containing 
for each active user of the system, credentials 
which allocate the user to a user id and to one or 
more user group ids and in that each object within 
each class has, as an attribute which may be inher- 
ited from object superclasses, an access control list 
(100) for identifying by user id and group id users 
having access privileges for maintaining the access 
control list of the object and for identifying opera- 
tions users are authorised to perform, the object da- 
ta manager being arranged to determine whether 
an operation on an object is permissible for a par- 
ticular user by comparison of ids in the access con- 
trol list of the object with the ids stored in the cre- 
dentials for the user. 

2. A system as claimed in claim 1 wherein the opera- 
tions include read, write and execute operations. 

3. A system as claimed in claim 1 or claim 2 wherein 
object data manager is arranged to determine the 
least amount of privilege associated with a compos- 
ite object accessed by a user 



Patentanspruche 

1. Objektorientiertes Datenbanksystem, das eine 
Hierarchie von Objekten (54, 55, 56, 57, 58) und 
einen Objektdatenverwalter (40) zum Zugreifen auf 
die Objekte umfaBt, gekennzeichnet durch eine 
Oder mehrere Tabellen (30), die fur jeden aktiven 
Benutzer des Systems Berechtigungsnachweise 
enthalten, die den Benutzer einer Benutzer-ID und 
einer oder mehreren Benutzergruppen-IDs zuord- 



nen, und dadurch, daG jedes Objekt innerhalb jeder 
Klasse als Attribut, das von Objektoberklassen ver- 
erbt sein kann, eine Zugriffssteuerliste (100) hat, 
urn mit Hilfe von Benutzer-ID und Gruppen-ID Be- 

5 nutzer mit Zugriffsprivilegien zur Pf lege der Zugriffs- 
steuerliste des Objektes zu identifiziereh und urn 
Operationen zu identifizieren, zu deren Ausfuhrung 
Benutzer berechtigt sind, wobei der Objektdaten- 
verwalter so eingerichtet ist, daG er erkennt, ob eine 

10 Operation an einem Objekt fur einen speziellen Be- 
nutzer zulassig ist, indem er IDs in der Zugriffssteu- 
erliste des Objektes mit in den Berechtigungsnach- 
weisen fur den Benutzer gespeicherten IDs ver- 
gleicht. 

75 

2. System, wie es in Anspruch 1 beansprucht wird, wo- 
bei die Operationen Lese-, Schreib- und Ausfuh- 
rungsoperationen entfallen. 

20 3. System, wie es in Anspruch 1 Oder Anspruch 2 be- 
ansprucht wird, in dem der Objektdatenverwalter so 
eingerichtet ist, da(5 er mindestens den Grad des 
Privilegs erkennt, das mit einem zusammengesetz- 
ten Objekt verbunden ist, auf das ein Benutzer zu- 

25 greift 



Revendications 

30 1. Systemedebasededonn6esorient6objet.com- 
prenant une hi6rarchie d'objets (54, 55, 56, 57, 58) 
et un gestionnaire de donn6es objet (40), destin6 a 
I'acces aux objets, caract6ris6 par une ou plusieurs 
tables (30) contenant, pour chaque utilisateur actif 

35 du systeme, des r6f6rences allouant I'utilisateur a 
des donn6es ^identification, jd, de I'utilisateur utili- 
sateur et a un ou plusieurs Jd de groupes d'utilisa- 
teurs, et en ce que chaque objet, dans chaque clas- 
se, a, a titre d'attribut pouvant etre h6rtte* de super- 

40 classes objet, une liste de commandes d'acces 
(100), pour identifier des utilisateurs par I'id utilisa- 
teur et I'jd de groupe, ayant des privileges d'acces 
pour conserver la liste de commande d'acces de 
I'objet et pour identifier des op6rations que les uti- 

45 lisateurs sont autoris6s a effectuer, le gestionnaire 
de donn6es objet 6tant agenc6 pour d6terminer si. 
une op6ration sur un objet est autoris6e pour un uti- 
lisateur particulier, par comparaison de ses id, se 
trouvant dans la liste de controles d'acces de I'objet, 

50 avec les jd stock6s dans les ref6rences destin6es 
a I'utilisateur. 

2. Un systeme selon la revendication 1, dans lequel 
les op6rations comprennent la lecture, l'6criture et 

55 !'ex6cution d'op6rations. 

3. Un systeme selon la revendication 1 ou la revendi- 
cation 2, dans lequel un gestionnaire de donn6es 
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objet est agence pour determiner la derniere quan- 
tity de privilege associ6e a un objet composite 
ayant subi un acces par un utilisateur. 
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